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n. >t to overcome any prior art. The amendments made incorporate terms of description 
ai id not of limitation 



A pplicants respectfully submit that the distinction between applicants' invention and 

ti tllining was addressed in applicants' parent applications. In the excerpts below, 

a] : plicants have indicated in bold face type in brackets where the cited portions of the 

p. urent specification are found in the current pending application [bold face in brackets 

fa :r current pending application J. In the parent cases it was noted that 

For the phrase "automated negotiations engine" support is found in the 
specification at Page 60, lines 9-20, Page 61 lines 1-18, and Page 62, lines 1-18, 
[Page 66, lines 5-18, and Page 67, lines 1-16] where the processing steps of the 
automated negotiations engine are described. On Page 62, lines 11-16 [Page 67, 
lines 9-14], for example, state: 

Whether or not a concluding document is requested, the system 
automatically displays the changes so they can be easily seen and the 
present invention also checks to see whether a state change is needed at 
Step 212-16. If a state change is needed it is initiated at step 21 2-20. 
Depending on the community, the participants, and the transactions 
involved, state changes could be as simple as payment authorizations sent 
electronically or as complex as multi-step processes desired by the 
participants. [Emphasis added] 

Also, as noted in the specification at page 52, lines 14-18 and Page 53, tines 1-4 
[Page 57, lines 3-12]: 

Next, in Figure 1L, network functions 207 of the present invention 
are shown. As mentioned above, most of the functions of multivariate 
negotiations en gine 212 are actually implemented as part of Webserver 
software 210s . As data is sent to and from the Internet 04 by Webserver 
210W, Webserver software 210s interprets the TCP-IP protocol and 
transfers the contents to multivariate negotiations engine 212's 
Webserver and dynamic HTML functions 207-02 . In one embodiment, 
these functions cause dynamic HTML text to be created to implement and 
communicate with the other functions of the present invention. Those 
skilled in the art will appreciate that Java, Java scripting , XML, or any of 
a number of other languages could also be used for such communications. 
[Emphasis added] 

Thus, it can be seen from these and other portions of the specification, amending 
the claims to clarify that the negotiations engine is an automated negotiations 
engine has ample support in the specification as filed. It is implemented in 
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computer software which is executed as part of Webserver software in the 
example referenced above. 

Support for the phrase "analyzing terms, the analysis of terms comprising 
understanding their purpose, formatting the terms according to the purpose and 
placing them into user supplied context for use by a user" is found in the 
specification at Page 86, lines 15-19 and Page 87, lines 1-4 [Page 92, lines 16-18 
and Page 93, lines 1-61: 

For example, and still in Figure 5a, if a buyer participant 08 wishes 
to place a proposed order, the browser encrypts it at the browser' s secure 
socket layer and webserver 210s decrypts the proposed order upon receipt 
at multivariate negotiations engine 02's site. Webserver 210s next analyzes 
the proposed order to understand it and formats into a request sent to 
database functions 222 , In addition to basic read and write functions, 
database functions 222 shown in Figure 5a. include operations such as 
search, analyze, compare, report, sort and relate (between databases.) 
Formatting can be as simple as "user = username" etc A request such as 
"find user=username, return catalog" might be sent through IP firewall 
203f ♦ (Emphasis added] 

User supplied context, which can be defined as a number of interrelated variable 
terms or items as noted in the specification at page 44, lines 19 and 20 [Page 48, 
lines 18-19 and Page 49, line 1], for example, includes rules supplied by a 
sponsor, terms and conditions supplied by a seller, terms supplied by a buyer, 
etc., as shown in more detail below. 

An example of "user supplied context" is found in the specification at Page 65, 

lines 7 -12 iPage 70, lines 8-13], where the user is a buyer: 

Now referring to Figure 15b, a typical proposal form for a buyer is 
shown. As seen here, the buyer identifies himself his title, his company, 
and the company's location at lines 332-342, At lines 344-350 information 
about the buyers designated freight forwarder is given. At line 350, 
document presentation terms are spec ific as well as at line 352^354, 358 
and so oa the detailed terms of the buyer's preferences for shipment 
[Emphasis added] 

Another example of "User supplied context* is found in the specification at 
page 45, lines 6-9 [Page 49, lines 7-10], where the user is a sponsor: 

The sponsoring standards body establishes the community, 
proposes initial standards, sets the rules for negotiations, encourages and 
monitors negotiations, and concludes with a finally agreed upon set of 
standards, with each step of each negotiation that occurred along the way 
archived. [Emphasis added] 

Still another example of "User supplied context" is seen in the specification at 
Page 49, lines 6-15 [Page 53, lines 11-17 and Page 54, lines 1-3 J, where the user is 
a seller: 
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Now turning to Figure lg, the present invention can be viewed as a 
series of interrelated processes as shown here. For a commercial 
community, there are seller processes, sponsor processes and buyer 
processes. Remote authoring 50, is a seller process which enables a 
registered seller in the community to create a seller Website within the 
community on which to include the seller's marketing and product 
information, along with pricing, terms, service offerings and so on. 
Information generated or created in this remote auth oring process 50 is 
automatically integrated with the community databases and listings . 
Promotion and brand identifying actions (such as registering the Web 
page with search engines) are taken automatically on behalf of the seller 
as well. [Emphasis added) 

Support for the phrases "iwognizing any changes in the terms" and "the 
automated negotiations engine indicating any changes" is found in the 
specification at Page 62, lines 1-3 [Page 66 lines 17-18 and Page 671ine 1]: 

Multivariate negotiations engine 212 keeps track of each set of 
chang es and can display them so that the changes proposed at each step of 
the negotiations are clearly and accurately recorded, [Emphasis added] 

US Patent No. 5,692,206, to Shirley et al (Shirley) was brought to applicants' 
attention as potentially rendering obvious applicants' invention's negotiations 
engine and indication of changes as part of a negotiations process. Applicants 
respectfully disagree. Shirley describes a document generation system which 
helps a user create a document for use in a negotiation, but it does not automate 
the negotiations process. (See Col 2, lines 11-45 in which it is clear that Shirley 
describes a system of libraries of standard terms from which a user can manually 
select one or more provisions.) Shirley discloses a "negotiating database" which 
is not an automated negotiations engine but simply a file or database for holding 
"one or more corporate suggestions 442 and one or more user notes 444." Col 5, 
lines 49-51. In Col. 7, lines 14-40, it is dear that Shirley describes a system in 
which the user selects from a library of standard contract provisions those 
provisions the user wants to incorporate into his or her contract proposal. This is 
not a negotiations process, but simply a way to create a proposed contract 
document that one party might send to another by regular mail, fax, or e-mail. It 
teaches away from applicants' invention by focusing on word-processing-like 
document assembly techniques, not on negotiation processes. 

Finally, Shirley does not teach, disclose or render obvious an automated 
negotiations engine for indicating changes in the proposed terms. Instead, it 
teaches away from this as well, by teaching a redlining feature in which "the user 
creates one or more redline documents 218/' CoL 7, lines 61-62. The user selects 
two text versions of a document for comparison and, as disclosed at CoL 11, lines 
46-58: 

If, at the decision Week 702, the user selects a redline function, the 
system controller 102 branches to a process block 718, At the process block 
718, the system controller 102 activates the redline unit 120. The redline 
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unit 120 prompts the user to select to [sic] files to be compared- A redline 
comparison is typically done between a current document and either a 
corresponding standard document or a previous revision of the same 
document The redline unit 120 generates a new file that specifies the 
differences between the two files selected by the user, without affecting 
the selected files. The redline unit 120 may be implemented, for example 
[sic] a redlining program such as CompareRite. [Emphasis added] 



Redlining, as described above, is a text comparison of two documents. Changes 
in the text are underlined, usually in red, or "redlined." The program that does 
the redlining does not analyze the changes in any way, or prompt actions as a 
result of them. 

Applicants' invention, by contrast, during the negotiations process, provides an 
automated negotiations engine that analyzes terms by understanding their 
purpose, formats them according to their purpose, and places them in a user 
supplied context for use by a user. The automated negotiations engine also 
recognizes changes in the terms and indicates what has changed. It can also 
prompt for additional information as a result of a change. For example, if a 
shipping term such as Ex Works, has changed to Deliver Duty Free, the 
automated negotiations engine system of applicants' invention knows what 
additional inf ormation to request from the user, such as the name of the user' s 
freight forwarder, and will format requests for that information. 

Support for this is found in applicants specification at Page 86, lines 15-19 and 
Page 87, lines 1-4 [Page 92, lines 16-18 and Page 93, lines 1-6], as referenced 
above, as well as in Figure 15 CM and Figure 15 C-2- 



A ;:>plicants respectfully submit that the above clarifications apply to the present 
a] i plication as well. Unlike redlining, applicants' invention analyzes terms, the analysis 
ol terms comprising understanding their purpose, formatting the terms according to the 
pi iirpose and placing them into user supplied context for use by a user. As shown above, 
ut i2r supplied context refers to the fact that users of applicants' invention can supply the 
cc ntext for one or more negotiations. In the illustrative examples shown in the 
sf ecification and the drawings, user supplied context has included, among other 
th ings: community rules; standards; buyer's terms; seller's terms; sponsor, seller, 
at d buyer processes; application programming interfaces; templates; administrative 
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ir formation; product information; procedures; text, image and south* files; deciding 
ei itities, and numerous other items, according to the kind of negotiation and the kinds 
o; users involved. Non-commercial users may supply very different types of user 
si ipplied context as shown in the parent application at Page 61, lines 2-6 [Page 65, line 
Hi and Page 66, lines 1-4). 

Lr the discussion with the Examiner, applicants were also asked to clarify the 

d: :;>tinctions between applicants' invention and that which is claimed and disclosed in 

U »> Patent. No. 6,055,519 issued to Kennedy et al on April 25, 2000, entitled 

"] rameworic for Negotiation and Tracking of Sale of Goods ("Kennedy"). 

A pplicants respectfully submit that Kennedy does not disclose, claim, nor render 
ol i vious an automated negotiations system for processing negotiations. The Kennedy 
s) stem does not process negotiations, but stores data representing the current state of a 
TH gotiation, to allow the user to monitor the state of a negotiation. This is stated in the 
A :»stract as follows: 

A computer implemented system and process are provided for negotiation and 
tracking of sale of goods. In this system and process, a negotiation enpine (16) 
operates to store data representing a current state (18) of a negotiation between a 
seller and buyer. The negotiation engine (16) stores the data within a framework 
for representing aspects of the negotiation between the seller and buyer. The 
framework includes a request object, a promise object and an acceptance object 
that can store a current description of a contract. The framework also includes a 
set of one or more delivery deals determined by the contract. Each delivery deal 
can have a delivery request object, a delivery promise object, and a deliveiy 
acceptance object that can store associated item deals and time periods for 
delivery of item deals. Each item deal can have an item request object, an item 
promise object, and an item acceptance object that can store individual sales- 
order line-items. The ne gotiation engine (16) thereby allows a user to monitor the 
current state of the negotiation . . . 
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T ids is also clear from the following text in the description of the Kennedy patent at 
C »1. 4, lines 4-17: 

Buyer 14 can have a negotiation client 22 that communicates with 
negotiation engine 16 across a network communication layer. Negotiation client 
22 can comprise a software application executed by a computer system and 
allows buyer 14 to query current state IS . Negotiation client 22 can be used to 
communicate requests and acceptances from buyer 14 to seller 12, and 
negotiation engine 16 can be used to communicate promises from seller 12 to 
buyer 14. The request promise and acceptance information can also be 
communicated through other means such as by fax, phone, etc. According to the 
present invention,, ne gotiation engine 16 provides a frameworic for maintaining 
current state 18 to reduce or eliminate any confusion about the status of lite 
negotiation and relevant terms*[Emphasis added) 

E: isentially, Kennedy stores data objects of limited types which represent a request, a 
pi omise or an acceptance. Since the data stored in the objects could have been 
c< -mmunicated by fax or telephone, it is clear that Kennedy is simply storing the data, 
n processing a negotiation. The Kennedy "negotiation engine" stores these objects, 
as id as will be seen below, uses the time stamps associated with each to determine the 
st situs of the "negotiation". 



T\ lis state monitoring is described at Col. 5, lines 50-57 as follows: 

In the present invention, the state that a negotiation is in can be 
determined, for example, from the relative values of four time stamps: the date 
that the most recent request was issued, the date that the most recent promise 
was offered, the date that the most recent acceptance was made, and the most 
recent date that the request was queued. If there is only a request issued date, 
then the negotiation can be identified as being in state 32, [Emphasis added]. 

K innedy also states at CoL 4,lines 26-35: 

In the embodiment of FIG. 2, the negotiation can move through twelve 
states. There are essentially five kinds of changes that can be made to cause state 
transitions: the buyer can issue a new request (R), the seller can offer a new 
promise (P), the buyer can queue a request (Q), the buyer can accept a promise 
(A), or the buyer can delete or withdraw a request (D). All five changes are not 
necessarily applicable to each state . In particular, the buyer can delete or 
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withdraw a request until it is accepted, but once accepted, the request can no 
longer be withdrawn by the buyer.[Emphasis added] 

T is makes it dear that the system itself is only reporting on state transitions. It is 

tt kicking what the buyer and seller have done in the past; as the description expressly 

sfl ;ites at Col 6, lines 19-25: 

...the negotiation process can thus be tracked between buyer and seller in 
constrained environments by providing a framework for progressing through 
the state diagram of FIG. 2 while also storing the current state of and relevant 
data for the negotiation [Emphasis added] 

T :te limitations on a buyer and seller are illustrated by the following sample, from col. 4, 

li i.es 48-54: 

From state 34, the buyer can do one of four things. The buyer can delete or 
withdraw the request which moves the negotiation bade to state 30. The buyer 
can issue a new request, moving the negotiation to state 36. The buyer can queue 
the existing request moving the negotiation to state 38, and the buyer can accept 
the promise, moving the negotiation to state 40. 

Ft i rther, Kennedy does not recognize the users as negotiators or recognize one of them 
as a deciding entity. 



Ir stead, Kennedy is simply monitoring and tracking the state of some very limited 

cc mmunications between a buyer and a seller. Even while describing some of its 

a< ! vantages, this is made apparent at Col. 6, lines 43-50: 

The present invention provides numerous advantages over conventional 
negotiation processes. First, the exact state of the negotiation is detailed in such a 
way that automated and semi-automated decision systems (such as planning 
systems, order fulfillment systems, purchasing systems, supply chain 
management systems, etc.) can work against the alternate state transitions, and 
deal with the changes in states over time. [Emphasis added.] 

T! lis, and similar sections of the specification make it readily apparent that this is a 
m »nitoring and reporting system, not a negotiations system. 
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Ii addition, the system appears to be primarily designed, for the use of planners (not 

m gotiators) for order or demand management systems in either a buyer's or seller's 

o) ganizatjon as seen at CoL 9, lines 57-64: 

The Request, Delivery Request and Item Request structures together 
model and provide a framework for requests from one site to another. The 
Promise, Delivery Promise, and Item Promise structures toge ther model and 
provide a framework for the supplying (promising) site's commitment back to 
the requesting site. These structures together implement what is traditionally 
called "Order Management" or 'Demand Management" Simplified variations of 
those structures are often called "orders." [Emphasis added] 

A ii part of this, the Kennedy specification describes some specific formats and types of 
rs quest, promise and acceptance objects, containing pre-defined fields for data such as 
qi i antity, due date, price, etc. If a buyer and seller use these pre-defined object formats 
aj d fields, the system can trade their communications and feed the specific data into 
01 der management or demand management systems. Alternately, as stated above, their 
cc iTespondence by telephone or fax can be stored in these formats and thus tracked. 



H i.e specification states at cot 14, lines 39-41 that "The basic information provided is the 
st ate of the negotiation for each order (e.g. whether the order is Requested, Promised, or 
A cepted)/' and, at Col. 14, lines 42-52 that- 
Additional information can be provided which is termed "problems". An 
example problem is an order whose Promise does not match the Request. 
Another example is an order that is Promised but not Accepted (part of the 
"basic information" mentioned above). Another example is an order that is 
not yet promised and is planned but the planned delivery is later than 
requested. These pieces of information are critical for a human or automated 
planner to juggle capacities and modify plans in a way that optimizes 
performance of the supply chain. [Emphasis added] 
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Ir furtherance of the above statement, the specification describes, at CoL 14, lines 66-67 
as id Col. 15, lines 1-3: 

. . - types of problems that can be identified. It covers the meaning of each 
problem, the data used to identify the problem, and where possible the 
resolution methods by which a human or automated planner could try to 
eliminate or reduce the severity of the problem. [Emphasis added] 



A : i example of one of the types of problems which the invention can identify is found at 
CdL 15, lines 10-21: 

A "Request Not Planned" problem indicates that the item request was 
issued after the item promise was offered— and— the ^delivery plan' has not been 
planned to satisfy the item request either there is no * delivery plan*, or the 
"delivery plan" is for the older item promise. This Problem will not occur if the 
delivery request has an infinite Mue s Date, the item request is for a zero 
quantity \ or the item promise was offered after the item request was issued (or 
last modified). To resolve this Problem, either pliminate or zero out the item 
request (unlikely), "offer* _a Promise and switch the ^delivery plan" to satisfy the 
promise, or create and/ or replan the "delivery plan* to meet the item 
request , [Emphasis added] 

A 3 this example, and the others show, this problem identification is done, for the most 
pj :rt, after the fact, when the negotiation has presumably completed and primarily for 
th is benefit of the planner or demand management system, not the negotiators. 



If the planner uses one of the recommended solutions to "fix" the problem, the system 

w tl update the problem data, and reflect that, as described in the specification as well, 

at Col 18, lines 1-13: 

As any change occurs to the data of a Request, Promise, Acceptance, 
Delivery Request Delivery Promise, Delivery Acceptance, Item Request, Item 
Promise, or Item Acceptance, the invention reanalyzes the data and updates the 
identified problems. Data changes cause some problems to be eliminated and 
potentially others to be created. The human planner can see these updates in a 
character-based user interface or a graphical user interface. The automated 
planner would see these updates bv notification of which problems are 
eliminated and which (if any) are created. For this purpose, the invention has a 
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database of problems and an interface to an au tomat ed planner which 
communicates the stream of created and destroyed problems , (Emphasis added) 



K mnedy does state, at Col. 18, lines 14-28 that in connection with such problems, : 

Changes can be made at any point in a negotiation, including after the 
negotiation is traditionally viewed as "complete" (Acceptance is made). 
After acceptance, the seller and buyer both have the ability to reopen 
negotiations. The seller is allowed to change the Promise to reopen 
negotiations- The buyer is allowed to change the Request to reopen 
negotiations. (The invention allows this, although some applications of the 
invention may not In a manufacturing operation, machine breakages and 
strikes really require that promises be broken. Likewise, a supplier can 
rarely be rigid with their customers' requests.) When such changes occur, 
request-promise-acceptance problem calculations can be rerun . However, a 
locking mechanism can be used to prevent request and promise data from 
changing and instead reporting a warning if any entity attempts to change 
such data. [Emphasis added.] 

It is clear both from the specification and the claims, that this identification of problem 
a nditions is used to, as Kennedy's Claim 14 puts it "pinpoint mistakes in the 
negotiation." 



K nnedy does not disclose or claim or render obvious a system for processing 

m gotiations, but a system for monitoring state transitions amongst a set of narrowly 

defined objects. 



K i nnedy does not recognize the users as negotiators nor does it recognize one of them 
a$ a deciding entity. It appears that one primary user of the system described in 
K nnedy is a human or automated planner and that actual negotiators are simply being 
m imitored by a system in which they can store data or in which data is stored about 
th tsir actions, which may have taken place by telephone or fax, and not through direct 
uf 12 of the monitoring system of Kennedy (see Col 4, lines 12-15: "The request, promise 
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aj id acceptance information can also be communicated through other means such as by 
fax, phone, etc.".) 

A ppKcmts respectfully submit that Kennedy is not a negotiations system at all, but; as 
it i ;ay s, a framework for a tracking or monitoring system for a very limited set of 
tr insaction types related to order and demand management for the sale of goods. 
K innedy does not disclose, claim, nor render obvious applicants' invention. 

A !>plicants respectfully submit that all bases for objection and rejection have been 
oi ercome and that Claims 2-98 are in condition for allowance. Reconsideration of all 
ti e claims is requested. Allowance of Claims 2-98 at an early date is solicited- 

A ;>plicants ' Attorney respectfully requests that if she can be of any further assistance in 
pi sitting all the claims in condition for allowance that she be reached by telephone at 
H i?-653-8143 or by cellular phone at 508-308-2109 in order to discuss the application 
w ith the Examiner, so that any new objections or rejections may be addressed. 

D i te: August 20, 2003 

Respectfully Submitted, 

Maureen Stretch 
Reg. No. 29,447 

C ist No. 27,443 26 Charles Street 

T< 1. 508-653-8143 Natick, MA 01760 
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